iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 19
1

良好程式碼的優點大同小異。
不好的程式碼的糙點卻各有巧妙之處。

面對技術債,該用什麼心情?

設計缺陷

原設計者: 「原本沒想到可以這樣做,原設計被事後諸葛,也無話可說,虛心接受吧」
再設計者: 「這技術債是無心之過,不是人為,是當時最佳決定了」

也許,當時世界頂尖技術還沒發展到至今,AngularJS 一開始也沒有單一資料流、狀態管理...,用 $scope.on('event') (廣播功能) 來解決非同步更新畫面的問題,也是理所當然。
也許,前端框架還沒有發展 Virtual DOM 所以把前端框架拿來當模板語言使用也是理所當然的。
也許,async/await 還沒有支援 node.js 時只能用 generator 寫類似的語法,用套件 co 也是時代的眼淚,再加上 co-expressco-functional...相信專案已是時代的淚流滿面。

也許有太多的也許?

設計缺陷,一定是某個接任者沒有決定調整方向!而這個就是糙點。
設計缺陷要自己擦屁股!!不然就留下待擦屁股的文件。

過氣的套件

有機會拔掉過氣套件,要拔掉!!

這種情況就像是,你使用了不良的命名。

看到這種東西,要弄懂它

  1. 查一下它是什麼
  2. 要學一下它是什麼
  3. 原來是做一些現在已經有替代方案的東西呀
  4. (對於這個問題,他現在才跟你有相同的認知,但是已花費了不少的時間,這些是不會讓自己進步的花費,就只是為了要消滅當初沒做的技術債)
  5. 然後計劃把它拔掉

如果你的專案,還是用bower 安裝套件?你要怎麼拔掉它?

缺少測試

原任開發者: 「這應該看就知道了吧?」
接任開發者: 「這....是什麼功能?」

有寫測試,在這個時代算是一個門檻,另一個境界的工程師。
除了可以滿足「定義自己已完成工作」,還可以給予接任工程師足夠的勇氣,繼續改下去。

常見的情況,是自己給自己勇氣。
自己補上自動化測試,是幸福。(還補得上)
有另一個人寫測試給自己,是奢華的幸福。[1]

不寫測試,不算糙 code ,算是沒有給予勇氣。
但是,可以的話,寫測試吧!都二十一世紀了...

若程式碼寫得不好,就該學測試來自我訓練,程式碼的可測試性提高,程式碼品質也會提高。
程式碼最接近規格的語意,就是用測試框架寫的程式碼了。

明知該實作,卻沒實作

這是要給誰擦屁股?

原任開發者: 「這...當初就是....所以就沒做了?」
接任開發者: 「所以,算我倒楣?要怎麼做?」

所有自己寫的程式碼,都應該要收尾擦屁股。一開始都會寫髒 code 沒錯。
學習任何技能都要知道,不要怕手髒。寫程式也是,不要怕 code 髒。(也許寫髒 code 的人就是不怕到一種極致了...QQ)

但是,等你熟悉問題,了解問題前因後果,並且將會動的程式碼放上去之後,請務必將程式碼整理、該做的最佳化要做。

如果這一切都有這麼多理由不做,這一切都有這麼多的原因,讓你斷了手無法將這份 code 的品質維護到一定的程度,那麼就寫文件吧。

意思是說,自己的實作要自己擦屁股!!不然就留下待擦屁股的文件。

這一切與消費者無關

若買到的 iPhone、車子導航系統 有哪並不完美,消費者會覺得,這是沒關係的嗎?
還是消費者覺得這是瑕庛品

當然這是一個不專業的說法,但是消費者就是如此。

參考資料

[1]: CHIMEI 2010 新奢華的幸福


上一篇
技術債是糙 code ?? (上)
下一篇
魔法般的 magic number
系列文
可不可以不要寫糙 code30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言